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Mr.  Chairman  and  Members  of  the  Subcommittee: 


I  am  pleased  to  submit  this  statement  for  the  record  as  part  of  the 
Subcommittee's  hearings  on  the  C-17  aircraft  program.  As  you  know, 
the  C-17  will  be  the  most  computerized,  software-intensive, 
transport  aircraft  ever  built.  Embedded  computers  are  essential 
for  the  C-17  to  accomplish  its  mission--the  aircraft  depends  on 
these  computers  to  control  basic  avionics  functions  such  as  flight 
control,  communication,  and  instrument  displays.  The  C-17  relies 
on  19  different  types  of  embedded  computers  incorporating  over  80 
microprocessors  and  about  1.3  million  lines  of  code.  This  statement 
provides  information  on  the  current  status  of  embedded  computer  and 
software  development  for  the  C-17. 

In  summary,  we  have  observed  a  pattern  of  the  Air  Force  continuing 
to  permit  its  prime  contractor,  McDonnell  Douglas  Corporation,  to 
defer  software  development  to  future  aircraft.  Originally,  the 
first  aircraft  (T-l),  delivered  in  September  1991,  was  supposed  to 
include  all  the  software.  But,  McDonnell  was  unable  to  develop  and 
deliver  the  software  on  time.  Rather  than  slowing  aircraft 
production  until  the  software  could  be  completed,  McDonnell 
deferred  software  development,  initially  to  the  P-2  aircraft,  then 
to  the  P-5  aircraft,  and  now  to  the  P-6  and  future  aircraft.  Each 
software  development  deferral  further  delays  the  Air  Force's 
ability  to  fully  test  the  software  and  demonstrate  that  the  C-17 
can  meet  all  of  its  requirements. 

The  Air  Force  is  continuing  to  experience  embedded  computer  and 
software  development  problems  on  the  C-17  in  three  major  areas. 
First,  some  critical  software  functions  are  either  still  being 
developed  or  are  incompletely  tested.  Although  McDonnell  has  made 
substantial  progress  in  the  past  year,  software  immaturity  still 
prevents  the  C-17  from  meeting  critical  mission  requirements  and 
severely  limits  testing.  Secondly,  McDonnell  continues  to  have 
problems  in  meeting  reserve  processing  and  memory  capacity 
requirements.  The  C-17's  embedded  computers  need  this  reserve 
capacity  to  service  future  growth,  but  the  Air  Force  continues  to 
waive  these  requirements  to  minimize  schedule  delays.  Lastly, 
McDonnell  has  still  not  developed  adequate  system  documentation, 
thereby  jeopardizing  the  Air  Force's  ability  to  efficiently  test, 
maintain,  and  upgrade  C-17  computer  systems. 

BACKGROUND 

In  May  1992  we  reported  that  the  C-17  faced  significant  software 
development  problems.1  The  Air  Force  made  a  number  of  major 
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mistakes  early  in  the  program  that  affected  its  ability  to  manage 
and  oversee  software  development.  Air  Force  officials  initially 
assumed  that  software  was  a  low-risk  part  of  the  C-17  program  and, 
therefore,  did  not  adequately  manage  its  software  development.  In 
addition,  McDonnell  and  its  subcontractors  used  software  to  solve 
several  aircraft  design  and  performance  problems,  further 
complicating  the  development  effort.  The  Air  Force  also  found  that 
they  lacked  specific  knowledge  about  software  problems  when  they 
first  occurred,  and  did  not  ensure  that  McDonnell  took  timely 
corrective  action.  Thus,  we  concluded  that  the  C-17  program  was  a 
good  example  of  how  not  to  manage  software  development  when 
procuring  a  major  weapons  system. 

We  also  reported  that  because  of  problems  and  delays  in  developing 
and  testing  software  and  the  lack  of  quality  system  documentation, 
McDonnell  (with  the  Air  Force's  concurrence)  took  a  number  of 
shortcuts  to  minimize  schedule  delays.  For  example,  McDonnell 
delayed  the  completion  and  installation  of  most  mission-critical 
software  functions,  such  as  navigation  and  communications,  until 
the  second  production  aircraft  (P-2) --the  avionics  test  aircraft. 
According  to  the  original  C-17  full-scale  development  contract,  the 
first  test  aircraft  (T-l)  was  to  include  all  of  the  software.  The 
Air  Force  also  "temporarily"  waived  reserve  processing  and  memory 
capacity  requirements  for  several  of  the  most  critical  computers, 
including  the  mission  computer  and  multifunction  display,  on  the 
first  five  aircraft.  Past  experience  on  major  Defense  software 
development  efforts  clearly  shows  that  taking  shortcuts  like  these 
and  not  solving  problems  promptly  greatly  complicates  and  makes 
more  costly  the  effort  required  to  make  the  software  function 
correctly. 

In  our  May  report  we  endorsed  Congressional  direction  that  Defense 
perform  and  submit  an  independent  "Early  Operational  Assessment"  of 
the  C-17's  mission  capabilities  following  completion  of  the  first 
50  hours  of  operational  flight  test.  We  also  recommended  that  the 
Secretary  of  Defense  expand  this  assessment  to  evaluate  (1)  the 
impact  of  software  risks  on  the  C-17  development  and  flight  test 
program,  and  (2)  Air  Force  plans  to  ensure  adequate  preparation  and 
approval  of  software  support  documentation.  As  discussed  below. 
Defense  evaluated  software  deficiencies  and  documentation  as  part 
of  its  Early  Operational  Assessment. 

EARLY  OPERATIONAL  ASSESSMENT 

In  its  December  1992  Early  Operational  Assessment  of  the  C-17,  the 
Defense  Director  of  Operational  Test  and  Evaluation  concluded  that 
immature  software  has  limited  testing  of  the  C-17's  operational 
capabilities,  such  as  flight  controls,  stall  warning, 
communications,  aerial  delivery,  and  navigation.  These  software 
shortfalls  are  now  affecting  the  C-17's  readiness  for  operational 
testing,  which  was  expected  to  start  in  September  1993.  This 
testing  has  now  been  delayed  until  January  1994.  In  addition,  the 
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Director  concluded  that  software  documentation  is  not  adequate,  and 
without  quality  documentation,  the  Air  Force's  ability  to  carry  out 
its  software  maintenance  activities  may  be  impaired.  This 
assessment  further  substantiated  the  software  problems  we  reported 
to  you  in  May  1992. 

CURRENT  STATUS 


The  C-17  is  still  plagued  with  many  of  the  same  software 
development  problems  we  identified  last  year.  McDonnell  has  still 
not  delivered  an  aircraft  with  a  fully  functional  avionics  suite, 
although  it  has  added  much  of  the  missing  functionality  through  a 
series  of  software  upgrades. 

When  serious  software  development  problems  led  to  schedule  slippage 
early  in  the  program,  McDonnell  revised  its  plans  It  concentrated 
its  development  efforts  on  those  basic  avionics  functions  needed 
for  initial  flight  testing  of  the  T-l  aircraft,  but  required  that 
all  subsequent  aircraft  be  100  percent  functional.  This  approach 
provided  the  software  needed  to  ensure  that  the  T-l  aircraft  could 
safely  take-off,  demonstrate  basic  flying  qualities,  and  land.  It 
also  allowed  McDonnell  to  delay  development  and  testing  of  the 
software  needed  for  more  sophisticated  avionics  functions  until 
delivery  of  the  P-2  aircraft. 

The  P-2  aircraft,  which  was  delivered  to  the  Air  Force  in  June 
1992,  about  six  months  late,  was  designed  to  contain  the 
specialized  instruments  (not  included  on  any  other  C-17  aircraft) 
needed  to  measure  and  record  C-17  avionics  test  results.  However, 
when  the  aircraft  was  delivered,  it  contained  only  55  percent  of 
the  mission  computer's  required  software  and  80  percent  of  the 
electronic  flight  control  and  communication  software.  Again, 
McDonnell  continued  its  software  development  and  improvement 
efforts,  while  planning  to  install  the  missing  software  on  future 
aircraft.  However,  it  was  understood  that  any  software  delivered 
on  future  aircraft  would  have  to  be  installed  and  retested  on  the 
P-2  aircraft,  which  would,  in  turn,  stretch  out  the  test  program. 

The  P-5  aircraft,  delivered  to  the  Air  Force  a  few  days  ago  on 
March  12,  1993,  still  does  not  contain  all  required  software.  Most 
significantly,  the  electronic  flight  control  system  does  not  have 
the  software  needed  to  perform  take-offs  and  landings  on  short 
airfields  and  low-altitude  parachute  drops,  two  key  mission 
requirements.  In  addition,  the  mission  computer  does  not  have  the 
required  software  for  critical  flight  and  navigation  maneuvers, 
such  as  flying  in  formation  and  joining  other  aircraft  at  selected 
geographical  positions.  The  Air  Force  granted  what  it  calls 
"temporary"  relief  from  these  software  requirements  to  maintain  the 
P-5  delivery  date,  which  is  critical  to  the  release  of  additional 
funding  for  the  C-17  program. 
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According  to  the  C-17  program  office,  McDonnell  is  planning  to 
install  some  of  the  remaining  missing  software  on  the  P-6  aircraft, 
expected  for  delivery  in  June  1993.  However,  McDonnell  does  not 
expect  to  have  some  required  software  until  March  1994--the  planned 
delivery  date  for  P-11.  And,  consistent  with  past  performance,  the 
program  office  expects  McDonnell  to  seek  a  new  waiver  for  software 
that  may  not  be  developed  by  this  date. 

McDonnell  also  remains  unable  to  meet  reserve  processing  and  memory 
capacity  requirements.  The  C-17  contract  specified  that  25  to  40 
percent  of  the  memory  and  processing  capacity  of  the  computers  that 
operate  C-17  avionics  and  flight  control  subsystems  had  to  be 
reserved  to  meet  future  needs.  Six  major  subsystems,  including  the 
mission  computer  and  multifunction  display,  do  not  meet  these 
requirements.  As  it  has  done  when  faced  with  software  problems  in 
the  past,  the  Air  Force  has  temporarily  waived  reserve  capacity 
requirements  for  these  subsystems,  not  only  for  P-5,  but  for  later 
production  aircraft  as  far  out  as  P-13,  expected  to  be  delivered  in 
June  1994.  If  computer  reserve  capacities  cannot  be  restored,  the 
Government  has  two  options:  grant  permanent  relief,  thereby 
accepting  the  aircraft  with  less  capacity  than  originally  required 
or  require  McDonnell  to  replace  the  C-17  computer  processors  that 
are  not  meeting  specifications. 

Finally,  the  Air  Force's  ability  to  test,  maintain,  and  upgrade 
C-17  computer  systems  is  in  jeopardy  because  McDonnell  has  still 
not  developed  adequate  system  documentation.  Without  good 
documentation,  a  computer  system  is  difficult  to  understand  and 
maintain,  and  there  is  less  assurance  that  system  modifications 
will  function  as  required.  In  the  past,  organizations  have  chosen 
to  redesign  and  rebuild  systems  because  poor  documentation  made  an 
existing  system  too  difficult  to  understand  and  modify.  For  those 
avionics  subsystems  the  Air  Force  plans  to  maintain,  less  than  half 
of  the  required  documents  have  been  approved  to  date. 

The  Air  Force  is  planning  to  partially  maintain  the  C-17  at  the  San 
Antonio  Air  Logistics  Center.  However,  without  adequate 
documentation,  it  cannot  effectively  establish  this  "in-house" 
capability  and  will  have  to  rely  more  on  McDonnell  or  the 
subcontractor  who  built  the  subsystem  to  provide  software  support. 


4 


